Week OverviewMon – Fri · 10 hours total · Lab completion verified by instructor
Networking tools, remote access, firewall, NFS, and Samba
Week 6 is the most practically satisfying week of the course — students configure real network services between their two VMs and from their Linux VM to the Windows host. They set up SSH key authentication (the professional standard), configure a firewall, share files over NFS between Linux machines, and configure Samba so Windows can access Linux files. There is no Friday mini-assessment this week; the lab work is verified by the instructor throughout the week, and students use Friday to catch up and prepare for the Week 7 exam.
Week at a glance
Monday
Network Tools
ip command suite, hostname, DNS, netplan manual NIC config
Tuesday
Remote Access: SSH
openssh-server, key-pair auth from Windows host, sshd_config hardening
Wednesday
Firewall: ufw
Enable ufw safely, allow/deny rules, subnet restriction, application profiles
Thursday
NFS
/etc/exports, exportfs, mount from desktop2 and Windows host
Friday
Samba + Exam Prep
smb.conf, Windows file sharing, permissions. Afternoon: exam review and Q&A
⭐ OverTheWire BanditStanding challenge — not assessed
Week 6 target: Levels 23–26
Level 23 requires reading and understanding a cron bash script that generates a password. Level 24 involves writing your own script to brute-force a 4-digit PIN. Level 25 introduces an unusual shell (more) that must be escaped. Level 26 requires using a text editor escape to get a shell — very advanced, a genuine challenge for strong students.
Learning OutcomesBy end of Week 6, students can…
Use ip command suiteCheck NIC status, set temporary IPs, view routes, resolve DNS — compare to ipconfig/nslookup
Configure SSH key authGenerate RSA key pair on Windows, copy public key to Linux, disable password authentication
Harden sshd_configRestrict authentication methods, limit users, and verify changes take effect
Configure ufw firewallEnable ufw, allow and deny ports, verify rules, test connectivity
Set up NFS sharingConfigure /etc/exports, publish with exportfs, mount from Linux client and Windows host
Configure SambaInstall and configure smb.conf for a Windows-accessible share with correct permissions
MondayLecture + Lab 6A · 2 hrs
Network tools — ip, hostname, DNS, and netplan
0:00–0:10
Recap
0:10–0:40
Lecture
0:40–1:50
Lab 6A
1:50–2:00
Debrief
- Lecture (30 min): Linux networking has evolved —
ifconfig is old, ip is current. The ip command suite: ip a (addresses), ip link (interfaces up/down), ip route (routing table), ip neigh (ARP table). Setting a temporary IP: ip address add x.x.x.x/mask dev eth0 — doesn't survive reboot. Persistent config on Ubuntu 24.04: netplan YAML files in /etc/netplan/. Hostname: hostnamectl set-hostname name — persists after reboot. DNS: Ubuntu uses systemd-resolved. resolvectl status shows DNS servers. cat /etc/resolv.conf — usually a symlink to the resolved stub. Bridge: ip a is ipconfig, ip route is route print, resolvectl is ipconfig /displaydns territory. lshw -class network for hardware details.
- Lab 6A (70 min): Before starting, disconnect the NIC in VM settings. Run
ip a — document the disconnected state, ping loopback. Reconnect. Run ip a again, document changes. Get MAC address, IPv6 address, gateway, and DNS using ip commands. Run lshw -class network. Rename the VM to the workstation sticker label using hostnamectl — verify it persists after reboot. Configure the NIC manually using netplan for a static IP, apply, test connectivity.
Windows bridge moment: Students with networking background will recognise everything here — they know what a gateway and DNS server are. The value is showing them the Linux tools that reveal the same information. Run both ip a and Windows ipconfig /all side by side if possible.
TuesdayLecture + Lab 6C · 2 hrs
SSH — encrypted remote access and key-pair authentication
0:00–0:10
Recap
0:10–0:35
Lecture
0:35–1:50
Lab 6C
1:50–2:00
Debrief
- Lecture (25 min): SSH (Secure Shell, TCP 22) is an encrypted protocol for remote command-line access — it replaces Telnet, which sends everything including passwords in plaintext and can be captured trivially with Wireshark. Client-server: the machine you connect FROM runs the ssh client, the machine you connect TO runs sshd (openssh-server). Password auth vs. key-pair auth: key-pair uses a public/private keypair — the public key goes on the server (authorized_keys), the private key stays on the client and never leaves it. Cannot be brute-forced. sshd_config hardening: PasswordAuthentication no, PermitRootLogin no, MaxAuthTries 3, AllowUsers student — restart sshd after any change.
- Lab 6C (75 min): Install and verify openssh-server (dpkg -l | grep ssh, systemctl status ssh, ss -tulpn | grep :22). Connect from Windows PowerShell with a password, create a file from the Windows session, verify it on the VM. Generate an RSA key pair on the Windows host with ssh-keygen, copy the public key to the VM with ssh-copy-id, confirm key-based login works. Harden sshd_config — set PasswordAuthentication no, PermitRootLogin no, MaxAuthTries 3, AllowUsers student — restart ssh, then verify key login still works and password login is rejected. Test SSH from desktop2 to see how AllowUsers behaves for other machines.
Critical order of operations: students must verify key-based login works before setting PasswordAuthentication no. Disabling password auth without a working key locks them out of SSH completely — the only recovery is the Hyper-V console. Demonstrate this and have students test key login explicitly before the sshd_config change.
WednesdayLecture + Lab 6B · 2 hrs
ufw — the uncomplicated firewall
0:00–0:10
Recap
0:10–0:35
Lecture
0:35–1:50
Lab 6B
1:50–2:00
Debrief
- Lecture (25 min): ufw manages iptables rules — the kernel-level packet filter — with an approachable frontend. Default policy: deny incoming, allow outgoing. Always allow SSH before enabling ufw, or the connection drops immediately and you may lock yourself out. Rule syntax: by port (
ufw allow 22/tcp), by service name using application profiles (ufw allow ssh), by subnet (ufw allow from 172.17.0.0/16). ufw status numbered shows rules with numbers for easy deletion. Bridge: ufw is Windows Firewall with Advanced Security, minus the GUI.
- Lab 6B (75 min): Inspect the default (disabled) state and list available application profiles. Allow OpenSSH, then enable ufw — verify default policies and that SSH still works from Windows. Allow HTTP and HTTPS, test from the Windows host browser. Deny Telnet (port 23) and record the full ruleset. Restrict SSH to the lab subnet only (172.17.0.0/16) rather than "anywhere". Add a custom port rule with a comment, then delete it by number. Discuss why outgoing traffic still works with default deny incoming.
Critical order of operations: the most dangerous student mistake is enabling ufw before adding an SSH allow rule. Demonstrate it once quickly — enable, connection drops — then re-enable with SSH allowed first. Students who understand the failure mode will never make this mistake in a real environment.
ThursdayLab 6D · 2 hrs
NFS — network file sharing between Linux machines
0:00–0:10
Recap
0:10–0:35
Lecture
0:35–1:50
Lab 6D
1:50–2:00
Debrief
- Lecture (25 min): NFS (Network File System) — share a directory from one Linux machine (server) so another Linux machine (client) can mount it as if it were a local disk. Server installs nfs-kernel-server, client installs nfs-common. Shares are defined in
/etc/exports: directory, allowed hosts/networks, options. exportfs -a publishes current exports. showmount -e shows what's being exported. Client mounts with: mount server:/path /mountpoint or mount -t nfs server:/path /mountpoint. Key export options: rw/ro (read-write/read-only), sync (write confirmed before response), no_subtree_check (performance), root_squash (root on client = nobody on server — security default). NFS works well Linux-to-Linux; less ideal for Windows (use Samba for that).
- Lab 6D (75 min): On desktop1 (server): install nfs-kernel-server. Create /home/student/nfs_share, add test.txt. Configure /etc/exports for the lab subnet with rw,sync,no_subtree_check. Run exportfs -a, verify with showmount -e. On desktop2 (client): install nfs-common. Create mount point. Mount the share. Verify test.txt is visible. Unmount. Then try from Windows host — add NFS Client via Windows Features, mount the drive, test access. Document whether it's read/write or read-only from Windows.
Two-VM payoff: This is the first lab where both desktop1 and desktop2 are used simultaneously in a client-server relationship — exactly as they were set up in Week 1. Students who have maintained both VMs cleanly will find this straightforward; those who neglected desktop2 will need to catch up.
FridayLab 6E + Exam Prep · 2 hrs
Samba — Windows-compatible file sharing from Linux
0:00–1:20
Lab 6E — Samba
1:20–1:55
Exam Q&A
1:55–2:00
Wrap
- Lab 6E — Samba (80 min): On desktop1 (server): install samba. Create /var/winshare. Edit /etc/samba/smb.conf — add a new share section with path, browseable, writable, valid users. Set a Samba password for the student account with
smbpasswd -a student. Restart smbd. Allow Samba through ufw (sudo ufw allow Samba) as soon as it's installed — this hasn't been opened before today. From Windows host: browse to \\desktop1-IP or map a network drive. Test read and write access. Add a second share with different permissions — one read-only, one read-write.
- Exam Q&A (35 min): Open Q&A session — students ask about anything from Weeks 1–7. Instructor goes through the practical exam format: what a scenario looks like, how tasks are presented, what counts as a correct verification. Emphasise: the exam uses their own VMs — students who know their own environment have an advantage.
No mini-assessment this week. Lab completion across the week is verified by the instructor via spot checks. Students should have working SSH key auth, a configured ufw, NFS mounting between both VMs, and a Samba share accessible from Windows before Friday ends.
Instructor verification checklist — Week 6
| Task | How to verify |
|---|
| SSH key auth working from Windows host | Student connects from host PowerShell without password prompt |
| Password auth disabled in sshd_config | Test with ssh -o PreferredAuthentications=password student@vm — must be rejected |
| ufw enabled with correct rules | sudo ufw status verbose — shows SSH and Samba allowed |
| NFS share accessible from desktop2 | Student mounts share on desktop2 and reads/writes test file |
| Samba share accessible from Windows host | Student maps network drive and creates a file |
What you need ready before Monday
Lab 6A–6E handouts printed
Both VMs (desktop1 and desktop2) running and on the same network
Windows host has PuTTY and Wireshark installed (optional Telnet demo)
NFS Client added to Windows via Features (can pre-install)
Lab network allows VM-to-VM and VM-to-host traffic